Code Review: Role-based access control implementation for Cadence-web with 7 commits addressing auth and domain workflows. Three critical issues remain: x-forwarded-proto header trusted without proxy validation (appears twice), useUserInfo staleTime set to 0 causing excessive refetches, and POST /api/auth/token accepting already-expired JWTs without exp claim verification.

1. ⚠️ Security: x-forwarded-proto trusted without proxy validation
   Files: src/app/api/auth/token/route.ts:22-27, src/components/app-nav-bar/app-nav-bar.tsx:157, src/components/app-nav-bar/app-nav-bar.tsx:164, src/utils/auth/schemas/cadence-jwt-claims-schema.ts:6, src/route-handlers/auth-token/helpers/get-cookie-secure-attribute.ts:3-7, src/route-handlers/auth-token/set-auth-token.ts:34, src/route-handlers/auth-token/clear-auth-token.ts:19

   In `getCookieSecureAttribute`, the `x-forwarded-proto` header is unconditionally trusted to determine the cookie's `Secure` flag. If the app is deployed without a reverse proxy that strips or overwrites this header, a client can send `x-forwarded-proto: http` over an HTTPS connection to force `secure: false`, causing the auth cookie to be sent over plaintext connections. Conversely, `x-forwarded-proto: https` over HTTP would set `Secure` but the cookie would never be sent back.
   
   Consider either: (a) documenting this as a deployment requirement, (b) adding a config option to trust/ignore the header, or (c) defaulting to `secure: true` in production and only relaxing for development.

2. ⚠️ Performance: staleTime: 0 on useUserInfo causes excessive refetches
   Files: src/views/shared/hooks/use-user-info/use-user-info.ts:15, src/components/app-nav-bar/hooks/use-auth-lifecycle.ts:10, src/views/domain-workflows/domain-workflows.tsx:23, src/views/shared/hooks/use-user-info/use-user-info.ts:9

   The `useUserInfo` hook sets `staleTime: 0`, which overrides the project-wide default of `staleTime: Infinity` (set in `react-query-provider.tsx` specifically to prevent immediate client-side refetches in Next.js). Because `refetchOnWindowFocus` defaults to `true` in React Query, every tab focus event triggers a new `/api/auth/me` request. Additionally, every component mount treats cached data as stale and refetches. Since `AppNavBar` (always mounted at layout level) and `DomainWorkflows` both consume this hook, this creates unnecessary duplicate requests on page loads.
   
   Consider using a reasonable staleTime (e.g., 30-60 seconds) or `Infinity` to align with the project default. The expiry-based logout timer in `AppNavBar` already handles token expiration, and the explicit `refetch()` calls in `saveToken`/`logout` ensure freshness after mutations.

   Suggested fix:
   // use-user-info.ts
   export default function useUserInfo() {
     return useQuery<PublicAuthContext, RequestError>({
       queryKey: ['auth-me'],
       queryFn: async () => {
         const res = await request('/api/auth/me', { method: 'GET' });
         return res.json();
       },
       staleTime: 60_000, // 1 minute; mutations call refetch() explicitly
     });
   }

3. 💡 Edge Case: POST /api/auth/token sets cookie for expired JWTs
   Files: src/route-handlers/auth-token/set-auth-token.ts:21, src/route-handlers/auth-token/schemas/token-request-body-schema.ts:3, src/route-handlers/auth-token/set-auth-token.ts:19-33, src/route-handlers/auth-token/schemas/token-request-body-schema.ts:1-15

   The `setAuthToken` handler validates the JWT format (three dot-delimited base64url segments) but does not decode or check the `exp` claim. An already-expired token is accepted and persisted as an HttpOnly cookie. The user gets correct feedback (the subsequent `/api/auth/me` call returns `isValidToken: false`), but the round-trip is wasted and leaves a useless cookie on the client.
   
   Consider decoding and checking `exp` server-side before setting the cookie to provide immediate 400 feedback.

4. 💡 Quality: Deprecated `act` import from `react-dom/test-utils`
   Files: src/views/domain-workflows/__tests__/domain-workflows.test.tsx:4, src/views/domain-workflows/__tests__/domain-workflows.test.tsx:33-46

   `act` imported from `react-dom/test-utils` is deprecated in React 18 and removed in React 19. The recommended import is `import { act } from '@testing-library/react'` (which your test file already imports `render` and `screen` from `@/test-utils/rtl`, likely re-exporting `@testing-library/react`).
   
   Additionally, the try/catch-around-`act` pattern for asserting render errors is fragile — whether the error escapes `act` depends on React internals and can break across versions. The previous ErrorBoundary approach was more reliable and idiomatic for testing components that throw.

   Suggested fix:
   import { act, render, screen } from '@/test-utils/rtl';
   // or restore the ErrorBoundary pattern for error assertion